<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Bone torches',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/05/24.jpg" alt="The parking lot outside my workplace" class="framed-centred-image" width="800" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			Materialised views are a way to store data calculated from data you&apos;re already storing (Silberschatz-Korth-Sudarshan, 2001).
			From that, anyone remotely familiar with how computers work should see one advantage and disadvantage of using and not using views: using a view makes queries faster because the data doesn&apos;t need to be recalculated every time, but they also require more storage space, as you&apos;re storing redundant data.
			If not using views, the reverse applies: you&apos;re saving storage space, but some queries will take longer to run because the data has to be recalculated.
		</p>
		<p>
			There&apos;s more to it than just those two obvious points though.
			The materialised view is redundant data.
			In other words, the data exists in multiple places.
			There&apos;s the main data and there&apos;s the materialised view consisting of pre-crunched data.
			When the main data gets updated, as it surely will, the materialised view will immediately fall out of sync with it.
			There are two ways of dealing with that.
			The first option is to recalculate the materialised view&apos;s data right away (Silberschatz-Korth-Sudarshan, 2001).
			That can mean either when the updating query is run, which will make queries that update data run more slowly, or it can mean recalculating the next time the view is used, which means making a later query that checks data take longer to run.
			(If updated immediately, this is known as immediate view maintenance, while if it&apos;s updated when a query on the view is done, it&apos;s known as deferred view maintenance.)
			In either of these cases, using the materialised view, while speeding up some queries, will actually slow down other queries!
			The advantage to not using views in this case is that while some queries remain slow, others remain fast.
			The second option is to allow the materialised view to hold the now-inconsistent data, and just update the materialised view&apos;s data periodically (Silberschatz-Korth-Sudarshan, 2001).
			(This is also known as deferred view maintenance.)
			In this case, the materialised view doesn&apos;t slow down queries, but instead causes incorrect data to be returned.
			In some cases, this approximate data is good enough.
			In other cases, it&apos;s not.
			In this situation, the advantage of the materialised view is speed, but the advantage of not using the materialised view is accuracy and precision.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Silberschatz-Korth-Sudarshan. (2001). <a href="https://my.uopeople.edu/pluginfile.php/476000/mod_book/chapter/187010/Database%20System%20Concepts%204th%20Edition%20By%20Silberschatz-Korth-Sudarshan.pdf">Database System Concepts, Fourth Edition</a>. Retrieved from <code>https://my.uopeople.edu/pluginfile.php/476000/mod_book/chapter/187010/Database%20System%20Concepts%204th%20Edition%20By%20Silberschatz-Korth-Sudarshan.pdf</code>
			</p>
		</div>
	</blockquote>
</section>
<section id="diet">
	<h2>Dietary intake</h2>
	<p>
		For breakfast, I ate my remaining two slices of banana French toast.
		For dinner, I had 380 grams of muffuletta.
		I didn&apos;t really make time for lunch though.
	</p>
</section>
<section id="mobile">
	<h2>The mobile&apos;s $a[SD] card</h2>
	<p>
		I completed most of an assignment today that was specifically about setting file permissions, so I took the opportunity while the commands were fresh in my mind to try it on the mobile&apos;s $a[SD] card.
		It was a complete success.
		This time, the permissions I set on the $a[SD] card&apos;s root directory stuck (read, write, and execute all allowed by the user, the group, and everyone else), even after being ejected and remounted.
		However, the mobile still complains that to read the $a[SD] card, you need elevated permissions.
		What.
		The.
		Squid.
		What does it want from me?
		How do I get the mobile to allow reading from and writing to the $a[SD] card by its own applications?
	</p>
</section>
<section id="Minetest">
	<h2></h2>
	<p>
		It occurred to me today that liquids are nodes, but they can be in the inventory in the form of full buckets.
		Therefore, I figured I should come up with elementally-enhanced versions of the liquids, too.
		Flowing liquids can&apos;t use a palette though, and if liquid sources can and I set them to, it&apos;ll look bizarre and ugly.
		Liquids should only be enhanceable by a single element, and because they can only be put into the inventory (under normal circumstances) by using iron buckets, that element should be iron.
		With that in mind, I made it my assignment to come up with what the iron-enhanced liquids should be.
	</p>
	<p>
		I came up with a few ideas, but none of them matter.
	</p>
	<p>
		It occurred to me that my latest idea as to how to create <code>minestats</code>&apos; other half is as terrible as every other idea I&apos;ve come up with.
		Palette-swapped versions of existing nodes, some of which have alternate effects?
		It&apos;s too boring.
		<code>minestats</code> deserves better.
		<code>minestats</code> deserves to be epic.
	</p>
	<p>
		That&apos;s okay though.
		I&apos;ve got a much better idea now.
		I&apos;m ignoring Minetest Game&apos;s existing nodes, aside from in the context of using them as crafting materials.
		The new plan is to add a bunch of new nodes that can be crafted.
		However, when they&apos;re crafted, they&apos;re inert and cannot be placed into the world.
		This&apos;ll actually be implemented as them being non-node items.
		From there, you can infuse one of the new nodes with elemental energy, which will convert it into a different item, this time one that&apos;s a node, and you can place that.
		These nodes will all use a palette, with the index determined by what element you infused them with, and may or may not have some cool effect.
		Foe example, one node I&apos;m kind of excited for will be a node for use in creepy builds: a bone torch.
		Craft bones with a mese lamp to get some number of bone torches.
		They&apos;ll look like giant arm bones sticking out of the ground with tiny mese lamps hovering above them.
		Only the lamp will be coloured by the element, not the bone.
		It&apos;s actually not a possible thing to implement well using node boxes, due to the way the texture gets applied to those, but with some effort, I think I can pull off a good mesh for them.
		Meshes are much less limited, and can handle this design well.
		These bone torches won&apos;t do anything though.
		They&apos;ll be a strong light source and they&apos;ll be decorative, but that&apos;s it.
	</p>
</section>
END
);
